With the increasing dependence of nearly all aspects of modern life on network-based communications, network security has, of necessity, become of primary concern to businesses, individuals, and governments alike. Network operators are therefore scrambling to keep up with the latest network penetration and abuse techniques, trying to not only safeguard against them, but also to actively track and identify the perpetrators of such malicious acts. These are therefore the “hard” problems in security management, namely: (i) protection from network device hacking and (ii) identification of the perpetrator.
In many cases, when a network administrator becomes aware that a perpetrator is attacking a network device such as, for example, a router, the administrator protects the network against the malicious actions of the perpetrator by simply shutting down the device and then restarting it. While this solves the short-term problem of the current attack, it does nothing to prevent the perpetrator from later attacking the restarted device, possibly even by the previously utilized mechanism. It also, of course, allows the perpetrator to escape unidentified and unapprehended, presumably to attack this or another network in the future. In addition, the functioning of the network is disrupted, perhaps causing significant denial of service to legitimate users.
A somewhat more sophisticated approach is sometimes employed that provides the network administrator with a modicum of information about the perpetrator's method of attack, intentions, and identity. In this type of an approach, a probe or similar mechanism is attached to a transmission medium and is used to read packet headers. If a packet source or destination is deemed suspicious, then the administrator may investigate further by keeping a close watch on the intended destination of the packet. One serious drawback of this type of approach is that it leaves the network continuingly vulnerable to the actions of an attacker. By the time the administrator understands what the attacker is up to, it may be too late to prevent damage to the integrity of the network.
Another approach that has been tried requires the network administrator to first identify a suspected malicious individual and then isolate that individual in a “secure” area, such as a “jail” or “padded cell”. The administrator then must simulate network responses by hand in an attempt to determine the individual's intentions. In one incident, described in detail in Firewalls and Internet Security: Repelling the Wily Hacker, William R. Cheswick and Steven M. Bellovin, Addison-Wesley, 1994, pp. 167-179, (“An Evening with Berferd”), the suspect was isolated in a network “jail” and then fed responses to his commands that were hand-entered as appropriate by the network administrator. The intent of the tools used in this case was not to simulate a system in real time, but rather to “watch the [suspect's] keystrokes, to trace him, learn his techniques, and warn his victims.” They “lur[ed] him to a sacrificial machine” and then “tap[ped] the connection.”
The limitations of this approach are self-evident: firstly, the network administrator's time is completely occupied with “playing network” for the entertainment of the suspect, to the detriment of any other tasks that need to be accomplished, and secondly, the suspect must be rather gullible in order to accept the serious delays incurred while the administrator formulates, inputs, and sends “safe” responses. A particular difficulty the administrator encountered in this case was making sure that the responses given were consistent, especially as many of the decisions about how the simulated system would act were of necessity made on the fly. The authors themselves admit that this approach had several inherent dangers, including that a more perceptive suspect might have fled quickly, or perhaps even escaped the jail and caused serious damage to the network. This approach also only works for those production-type network devices that provide responses that are capable of simulation by a human administrator.
Another security approach that has been utilized is use of a “honey pot.” A honey pot is an essentially sacrificial device that is set up as part of a network. The honey pot is specifically designed to entice individuals with malicious intent into invading it and then displaying that malicious intent. The honey pot emulates a production server while alerting administrators to, and permitting logging of, the activities of any intruders. The honey pot's main goal is to attract intruders away from the real servers. In order to work, the honey pot therefore usually needs to be positioned close to production servers and needs to be in some way more attractive than they are. The honey pot does not actually substitute for any of the production servers, but is rather merely a decoy that is intended to distract a malicious individual away from real servers, at least long enough for the individual's techniques to be observed and, ideally, for the individual to be caught.
The drawbacks of this approach are several. For one, there is no guarantee that a malicious individual will even notice the honey pot, much less allow it to be a distraction from the individual's original intended target. The remainder of the network remains completely vulnerable to anyone who does not notice the honey pot or chooses not to take the bait. Further, a honey pot is obviously useless in actually defending against an attack that is directed against another device or transmission medium in the network. The honey pot only works if it can lure away the malicious individual; if it fails to do so, the network is completely undefended. While honey pots work on the concept that all traffic to a honey pot is deemed suspicious, if the malicious traffic is to another device, then the presence of a honey pot will do nothing at all to protect the integrity of the network.
Existing commercial honey pots also are somewhat limited in their ability to effectively emulate the various types of network devices or media. They generally run on production equipment and do not provide a full simulation of non-production services. The emulation software must therefore know about a particular vulnerability prior to its exploitation in order for it to be emulated properly. If the vulnerability is new or unknown, it is highly likely that the emulation will fail and the honey pot will be revealed. The alternative to emulation is very time- and resource-intensive: full-blown, dedicated systems of each type that serve no purpose other than to act as an intruder jail and observation area. Few networks can afford to have the resulting plethora of separate dedicated systems that would be needed in order to have the ability to replace every device and transmission medium on the network.
What has been needed, therefore, is a way to secure the integrity of an entire communications network from the malicious actions of a perpetrator, while still enabling automatic responses to, and recording of, those actions. This will in turn allow for further analysis that will ideally lead to (i) identification of the mechanism by which the perpetrator has attacked the network, in order that that avenue of attack can be eliminated from use by future attackers, and (ii) identification and apprehension of that particular perpetrator.